****************************************************************************
****************************************************************************

BIRD ID#:       {TBD}
ISSUE TITLE:    Back-channel support
REQUESTOR:      Marcus Van Ierssel, Snowbush IP
                Kumar Keshavan, Sigrity, Inc.
                Ken Willis, Sigrity, Inc.
DATE SUBMITTED: April 6,2011
DATE REVISED:
DATE ACCEPTED BY IBIS OPEN FORUM:

****************************************************************************
****************************************************************************

STATEMENT OF THE ISSUE:

This BIRD defines how back-channel communications is to be handled in the
IBIS specification. It requires BIRD120 (flow BIRD) and BIRD128 (AMI_GetWave
passing AMI_parameters_out/in) as a prerequisite. This BIRD also
entails:

- new Reserved_Parameters
- definition of a "back-channel" AMI file
- flow updates to enable the back-channel training to occur

****************************************************************************

STATEMENT OF THE RESOLVED SPECIFICATIONS:


Replace the following text in Section 6c:

|               Reserved Parameters:
|
|               Init_Returns_Impulse, Use_Init_Output, GetWave_Exists, 
|               Max_Init_Aggressors and Ignore_Bits


With the following text:

|               Reserved Parameters:
|
|               Init_Returns_Impulse, Use_Init_Output, GetWave_Exists, 
|               Max_Init_Aggressors, Ignore_Bits, TrainEnable, and Train

Add the following text after the description for "Ignore_Bits":

                TrainEnable:

                TrainEnable is of usage In and type String. It tells the
                EDA platform whether training for back-channel communication
                is enabled or not for the associated model. For the back-
                channel training to be enabled in the EDA tool, the
                TrainEnable parameter must be set to "on" for both the
                transmitter and receiver of a given through channel. The
                syntax for this parameter is as follows:

                (TrainEnable (Usage In) (Type String) (List “on” “off”)
                (Default “off”) (Description "Turns training on or off"))


                Train:

                Train is of usage In and type String. It tells the
                EDA platform what back-channel protocol is to be used for
                the back-channel training process. This is defined in a
                standard-specific back-channel AMI file. Both the
                transmitter and receiver for a given through channel must
                have identical settings for the Train parameter for back-
                channel training to be enabled. An example of the syntax
                for this parameter is as follows:

                (Train (Description "This Device can support back-channel
                training for multiple standards.") (Type String) (Usage In)
                (List “standard1.ami” “standard2.ami” “standard3.ami”
                “standard4.ami) (Default “standard1.ami"))

There are a number of Reserved_Parameters that are used solely for the
purpose of enabling back-channel communication, in which a receiver
provides information back to its associated transmitter in order to assist
in optimizing that transmitter's equalization parameters, in the context of
a particular industry standard. These additional back-channel Reserved
Parameters are listed below, and are used only in a back-channel AMI file:

                Reserved Parameters for Back-Channel Communication

                Frame, Marker, Data, PRBS, LFSR, LFSR_Seed, Len, Trailing
                Max_Train_Bits, BackChanControls, TrainDone

Descriptions for each are listed below.

Frame:

Frame is of usage Info and is the keyword used to describe the bit pattern
sent from the transmitter to the receiver during the back-channel training.

Marker:

Marker is of usage Info and defines the leading bit pattern that starts a
back-channel training Frame.

Data:

Data describes the bit pattern that the EDA tool should generate to serve as
the body of the Frame.

PRBS:

PRBS is described by the sub-parameters LFSR and LFSR_Seed.

LFSR:

LFSR is of usage Info and describes the value associated with a linear
feedback shift register used by the EDA tool for the PRBS generation.

LFSR_Seed:

LFSR_Seed is of usage Info and describes the starting seed to be used by the
EDA tool for the PRBS generation.

Length:

Length is of usage Info and describes the length of the PRBS pattern to be
generated by the EDA tool.

Trailing:

Trailing is of usage Info and describes the trailing bits used to indicate the
end of the training pattern. This is used by the EDa tool to determine the end
of the particular training pattern.

Max_Train_Bits:

Max_Train_Bits is of usage Info and defines the total number of training bits
that can be sent by a transmitter during the back-channel communication. This
tells the EDA tool when the back-channel training is complete, if the receiver
does not indicate it first with the TrainDone parameter.

BackChanControls:

BackChanControls is defined by its sub-parameters. These sub-parameters can
be of any name and of any legal IBIS-AMI syntax. They must be of Usage InOut,
and are used to pass information between the transmitter and receiver during
back-channel communications. it is implied here that both the transmitter
and receiver understand the sub-parameters defined in the BackChanControls
section of the back-channel AMI file indicated by the Train parameter.

TrainDone:

TrainDone is of usage Out and is issued by the receiver model to signify the
completion of back-channel training.

An example template for a back-channel AMI file is given below:

(standard_xyz
 (Reserved_Parameters
  (Frame (Description "Defines the training pattern")
   (Marker (Usage Info) (Type Integer) (Table (1 1 1 1  1 1 1 1  1 1 1 1  1 1 1 1  0 0 0 0  0 0 0 0  0 0 0 0  0 0 0 0))
    (Description "Leading marker pattern"))
   (Data
    (PRBS (Description "PRBS for this specific standard")
     (LFSR (Usage Info) (Type Integer) (Table (23 18 1)) (Description "Linear feedback shift register"))
     (LFSR_Seed (Usage Info) (Type Integer) (Table (0 0 0  0 0 0 0  0 0 0 0  0 0 0 0  0 0 0 0  0 0 0 1)))
    )
    (Length (Usage Info) (Type Integer) (Value 4094) (Default 4094) (Description "Length of PRBS bit stream after Marker"))
   )
   (Trailing (Usage Info) (Type Integer) (Table (0 0)) (Description "Trailing zeros"))
  )
  (Max_Train_Bits (Usage Info) (Type Integer) (Value 500000) (Default 500000) (Description "Number of total training bits allowed")) 
  (BackChanControls (Description "Reserved parameter. Standard-specific controls are defined under this section.")
   (BC_ControlA (Usage InOut) (Type Integer) (List -1 0 1) (Default 0)
                          (Description "Parameter name is standard-specific, and can be any legal Type"))
   (BC_ControlB (Usage InOut) (Type Integer) (List -1 0 1) (Default 0)
                          (Description "Parameter name is standard-specific, and can be any legal Type"))
   (BC_ControlC (Usage InOut) (Type Integer) (List -1 0 1) (Default 0)
                          (Description "Parameter name is standard-specific, and can be any legal Type"))
  )
  (TrainDone (Usage Out) (Type Integer) (Range 1 0 1) (Default 0) (Description "Signifies training is completed"))
 )
)

Note in the example above that the sub-parameters prefixed by "BC_Control"
are not reserved keywords, but indicate placeholders where sub-parameters
for BackChanControls would exist. As indicated previously, these can be of
any name and contain any legal IBIS-AMI syntax.



Replace the following text in Section 2.3 of Section 10 (NOTES ON ALGORITHMIC
MODELING INTERFACE AND PROGRAMMING GUIDE), once BIRD120 is incorporated into
the IBIS specification

| 3 Reference Flows
| =================
|
| The next two sections define a reference simulation flow for statistical
| and time domain system analysis simulations.  Other methods of calling
| models and processing results may be employed, but the final simulation
| waveforms are expected to match the waveforms produced by this reference
| simulation flow.
|
| A system simulation usually involves a transmitter (Tx) and a receiver
| (Rx) model with a passive channel placed between them.  


With the following text:

3 Reference Flows
=================

The next several sections define reference flows for back-channel training,
statistical analysis, and time domain system analysis simulations. Other
methods of calling models and processing results may be employed, but the
final simulation waveforms are expected to match the waveforms produced by
these reference flows.

A system simulation usually involves a transmitter (Tx) and a receiver
(Rx) model with a passive channel placed between them.  


3.1 Back-Channel Training Reference Flow
========================================

Some industry standards for serial link interfaces utilize back-channel
communications as a means by which the Rx can communicate back to the Tx
to provide guidance as to the equalization settings of the Tx, to optimize
for the given channel. Once the back-channel training is completed and the
Tx equalization settings are optimized, then time domain simulation is
performed per the "Time domain simulation reference flow" defined later in
this specification.

Note that back-channel training does not apply to statistical simulation,
as back-channel training utilizes the AMI_GetWave function in both the
Tx and Rx, and is therefore not applicable to statistical simulation. 

To enable the back-channel training to occur, the .ami files for both Tx
and Rx of a given through channel must have the GetWave_Exists parameter
set as "True", the TrainEnable parameter set to "on" and the Train
parameter specifying the same back-channel AMI file.

Step 1. The simulation platform obtains the impulse response for the
analog channel, as described in the statistical and time domain simulation
flows.

Step 2. The simulation platform produces a digital stimulus waveform
as defined per the back-channel AMI file. A digital stimulus waveform
is 0.5 when the stimulus is "high",  -0.5 when the stimulus is "low",
and may have a value between -0.5 and 0.5 such that transitions occur
when the stimulus crosses 0.

Step 3. The output of Step 2 is presented to the Tx model's AMI_GetWave
function. If the Rx model's AMI_GetWave function has written out the
BackChanControls parameters from a previous training sequence, these
parameters are read in. Then the Tx AMI_GetWave function is executed.
The output of the Tx AMI_GetWave function is passed on to Step 4. The
BackChanControls parameters defined in the back-channel AMI file are
written out by the Tx model's AMI_GetWave function.

Step 4. The output of Step 3 is convolved with the output of Step 1 by the
simulation platform and the result is passed on to Step 5.

Step 5. The output of Step 4 is presented to the Rx model's AMI_GetWave
function, the BackChanControls parameters from the Tx are read in, and the
Rx AMI_GetWave function is executed.  The BackChanControls parameters are
modified and output by the Rx AMI_GetWave function.

Step 6. Steps 2-5 are executed iteratively until the Rx model's AMI_GetWave
function returns the value of the TrainDone parameter as "1", or until the
Length parameter defined in the back-channel AMI file is exceeded, whichever
occurs first.

Step 7. With the Tx equalization settings optimized through back-channel
communication, the "Time domain simulation reference flow" is executed directly.

****************************************************************************

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:

Back-channel communication is required for PCI Express Gen 3, 10GBASE-KR,
and other emerging serial link standards. Back-channel capability was
initially developed by Sigrity and Snowbush (IP division of Gennum). It was
deemed desireable to bring this capability to the IBIS standard in order
to encourage other SerDes IP suppliers to enable back-channel functionality
for their IP as well.

****************************************************************************

ANY OTHER BACKGROUND INFORMATION:

The following documents are provided as supporting material for this BIRD:

- "Extending IBIS-AMI to Support Back-Channel Communications", by
  Marcus Van Ierssel of Snowbush, Kumar Keshavan of Sigrity, Inc., and Ken
  Willis of Sigrity, Inc., delivered at the IBIS Summit on Feb. 3, 2011:
  http://www.sigrity.com/papers/2010/IBIS_AMI_Modeling_May_2010.pdf

- "BIRD Proposal: Extending IBIS-AMI to Support Back-Channel Communications",
  by Marcus Van Ierssel of Snowbush, Kumar Keshavan of Sigrity, Inc., and Ken
  Willis of Sigrity, Inc., delivered at the IBIS-ATM subcommittee meeting on
  March 15, 2011:
  http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20110315/kenwillis/
  Proposed%20BackChannel%20BIRD%20Modifications/Proposal_BackChannel_BIRD_mods.pdf

- One issue still to be resolved is how standard-specific back-channel
  parameters under BackChanControls will be managed. This could possibly be
  done by the IBIS-ATM sub-committee and posted to the IBIS website.

****************************************************************************